home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 948 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB
  1. From: "Wil Evers" <wil@ittpub.nl>
  2. Message-ID: <009A04DA6A831C40.49800EAC@ittpub.nl>
  3. X-Original-Date: Wed,  3 Apr 96 11:37:34 WET
  4. Path: in2.uu.net!bounce-back
  5. Date: 03 Apr 96 14:38:46 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Organization: -
  8. Newsgroups: comp.std.c++
  9. Subject: Re: sample auto_ptr template
  10. X-Vms-Mail-To: IN%"std-c++@ncar.ucar.edu"
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMWKNiuEDnX0m9pzZAQGJdQF9HLlV54hOVi3yapAjSoHOjFsU+YoQ7cqu
  13.     OzcIFKBlG37l4oDXyA1/913snLfNBKpY
  14.     =4Cxs
  15.  
  16. Hi,
  17.  
  18. In article <gregorDp23ts.Axt@netcom.com> gregor@netcom.com (Greg Colvin)
  19. writes:
  20.  
  21. > In Santa Cruz we decided to change the auto_ptr copy semantics to
  22. > allow returns of auto_ptr from functions.  Following is a simple
  23. > implementation.  
  24. >
  25. > [snip]
  26. > 
  27. > template<class X>
  28. >    class auto_ptr {
  29. >       mutable bool owner;
  30. >       X* px;
  31. >       template<class Y> friend class auto_ptr;
  32. >    public:
  33. >       explicit auto_ptr(X* p=0) 
  34. >          : owner(p), px(p) {}
  35. >       template<class Y>
  36. >          auto_ptr(const auto_ptr<Y>& r) 
  37. >             : owner(r.owner), px(r.release()) {}
  38. >       template<class Y>
  39. >          auto_ptr& operator=(const auto_ptr<Y>& r) {
  40. >             if ((void*)&r != (void*)this) {
  41. >                if (owner) 
  42. >                   delete px;
  43. >                owner = r.owner; 
  44. >                px = r.release();
  45. >             }
  46. >             return *this;
  47. >          }
  48. >       ~auto_ptr()           { if (owner) delete px; }
  49. >       X& operator*()  const { return *px; }
  50. >       X* operator->() const { return px; }
  51. >       X* get()        const { return px; }
  52. >       X* release()    const { owner = 0; return px; }
  53. >    };
  54.  
  55. If I don't misunderstand the above implementation, it does much more
  56. than just allow auto_ptrs to be returned from functions.  It also
  57. allows auto_ptrs to be dereferenced after the ownership of the pointee
  58. has been transferred to another auto_ptr.
  59.  
  60. Is this intentional?  Did the committee explicitly decide to allow
  61. dereferencing of non-owning auto_ptrs?  If so, what is the rationale behind
  62. this? 
  63.  
  64. It seems to me that after the ownership has been transferred, the
  65. no-longer-owning auto_ptr points to an object of undetermined ownership
  66. and lifetime. In other words, its behavior is in no way different from
  67. a built-in pointer.
  68.  
  69. The old (April 95 DWP) definition of auto_ptr at least guaranteed that if an
  70. auto_ptr was pointing at something, it was pointing at a unique and alive
  71. object.  Now, we don't even have a way to query if this is the case. 
  72.  
  73. This is a terrible state of affairs, especially when we realize
  74. auto_ptr is the *only* smart pointer we have in the standard library.
  75. In my opinion, it should be renamed to zombie_ptr if it is to keep its
  76. new semantics.
  77.  
  78. - Wil
  79. ---
  80. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  81. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  82. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  83. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  84. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  85.